What were the motivations for java to use the @Override annotation, instead of creating a new override modifier?

public String toString() {
   return "";


public override String toString() {
   return "";
  • 2
    That was an afterthought. Commented Aug 5, 2016 at 12:32

3 Answers 3


@Override was originally not in the language. When the need was felt to add it, it was easier to use a generic mechanism (annotations) than to add a new keyword to the language. Adding a new keyword is always an incompatible change since it can break programs which use that words as an identifier.

In languages which add an override marker right from day one, it is quite often a keyword (examples are Kotlin and Scala), in Java it was a matter of staying backwards-compatible with older Java version which did not have any override marker.

  • 1
    It seems inconsistent that override is an annotation, when there have been changes that have introduced new keywords. For example the "default" modifier for interface methods.
    – jwa
    Commented Aug 5, 2016 at 9:14
  • 7
    @jwa Not really: default was already a reserved keyword (used in switch statements) - they just added a new use for it. There are also a few keywords which do not do anything right now but are reserved for future use (const, goto) - see JLS §3.9 Commented Aug 5, 2016 at 9:19
  • 4
    "examples are Kotlin and Java" looks like a typo here, did you mean to write eg Scala instead of Java?
    – gnat
    Commented Aug 5, 2016 at 9:26
  • 8
    whilst it is true that adding global keywords breaks stuff, it could have been added as a contextual keyword without breaking code. one assumes this wasn't done as it would slightlt complicate parsing and the annotation mechanism was sufficiently good
    – jk.
    Commented Aug 5, 2016 at 9:43
  • 1
    @MichałKosmulski: I remember the enum keyword that was added would break older code. More breaking keywords here: stackoverflow.com/questions/16506411 Commented Aug 11, 2016 at 19:03

You don't need the @Override annotation to actually override behavior; It's an annotation because it's simply adding some context of the method's intent for the compiler, not changing the method itself.

Without the annotation, you may intend to override functionality, but accidentally fail to do so (by using a slightly different signature). Adding the annotation tells the compiler to generate an error if this method isn't actually overriding behavior.

As such, it makes perfect sense as an annotation.

  • +1 It makes sense that similar to disabling warnings through annotations it would also be possible to enable optional warnings/errors through annotations.
    – Hulk
    Commented Aug 6, 2016 at 7:27

Very good question!

In general, as we can see from other programming languages, the intention of overriding a class member is expressed via a keyword. This is logical, because keywords are intended to be processed by the compiler, and their effect is manifested only during compilation. At runtime, the program has the keyword effect already baked in. This type of behavior establishes that a keyword has a stronger and more persistent effect on a program's behavior.

On the other hand, we have ways to add metadata to the code we write. In java and other JVM languages, we use annotations. In .NET the same things are called attributes. Nevertheless, in the majority of cases, annotations are intended to be interpreted at runtime, where they may introduce additional behavior to a program. This type of behavior is weaker than the compiled code, as it could be turned on or off (let's say via configuration), or its implementation changed -- all of which can be decided at runtime. Also, those type of behaviors are not always transparent of what actually happens behind the scenes (AOP anyone?), compared to the degree of clarity we get with a keyword.

Still, in Java we see a fundamental operation in the object-oriented design, such as overriding an inherited member, to be expressed in a weaker manner than let's say the transient keyword which says whether a field will be serialized or not. While we can argue that serialization is more of a runtime concern, we can all agree that overriding is a job for the compiler. If you always felt that an annotation is not quite right for the job this means you are making good sense of things. So, how did we end up here anyway?

Well, the @Override annotation in java is an example of an elegant workaround. The folks who created the language allowed implicit overriding of class members by design (without either a keyword or annotation), but as different APIs started to pop out taking on the object-oriented features of the language, soon major bugs appeared because people did not really understood when they were overriding a parent class's member. Unintended overrides would fail to call the base member defined in the super class, and programs would therefore misbehave.

Today, we deem inheritance as a bad OOP design practice, but in the earlier years of OOP it was quite abused -- no wonder we came to the conclusion it was a bad idea. Anyway, in those confusing times, the language designers understood the need to make overriding more noticeable among developers, and also understandable by the compiler. Introducing a keyword would have been a working solution, except for breaking backwards compatibility. And the Java language is known for having a very very strong backwards compatibility policy, on which the reliability and scalability of the Java platforms stands. The only acceptable solution -- that would not break existing code and still accomplish the effect of a keyword -- was to introduce an annotation, and make the compiler understand it. Until this day, Java stays true to its backwards compatibility covenant, sticking with that same annotation. We can get slightly irritated when we have to use it instead of a regular keyword, but it is a good example of an elegant workaround (don't we programmers pride ourselves on those?), and a good reminder of how a good intention (as was the implicit overriding at first) could pave a road to hell.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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