@Override

B

bob smith

Is it really necessary to write @Override when you override or is this just "a good thing"?
 
D

Daniele Futtorovic

Is it really necessary to write @Override when you override or is this just "a good thing"?

Just a good thing. Catches cases where you aren't actually overriding.
 
M

markspace

Is it really necessary to write @Override when you override or is
this just "a good thing"?


Well, it's "just a good thing," but it's *really* a good thing. If you
were programming professionally, you'd expect your boss (or coworkers,
say during a code review) to insist that you use @Override wherever
appropriate.

In short, "just do it."
 
L

Lew

markspace said:
bob smith wrote:
Is it really necessary to write @Override when you override or is
this just "a good thing"?

Since when does "a good thing" ever deserve a "just"?

If it's a good thing, what's your objection?

Did you read the docs on '@Override'?

<http://docs.oracle.com/javase/specs/jls/se7/html/jls-9.html#jls-9.6.3.4>
<http://docs.oracle.com/javase/7/docs/api/java/lang/Override.html>

Why not?

Seriously, why in the world would you not want to use '@Override'?

Based on the documentation, now that you're aware of it, rephrase
your question as "What are the advantages and disadvantages of
'@Override'?" Then evaluate its utility.
Well, it's "just [sic] a good thing," but it's *really* a good thing. If you
were programming professionally, you'd expect your boss (or coworkers,
say during a code review) to insist that you use @Override wherever
appropriate.

In short, "just do it."

OP: There is benefit to using '@Override' and serious risk of harm if you don't.

Consider 'Object#equals()'.

public class BadEquals
{
private String attribute = "";
public String getAttribute() { return attribute; }
public void setAttribute(String attr) { this.attribute = (attr == null? "" : attr); }
public boolean equals(BadEquals other)
{
if (this == other)
{
return true;
}
if (other == null)
{
return false;
}
return getAttribute().equals(other.getAttribute());
}
}

Let's say you have another class that uses a collection of 'BadEquals'.

Without '@Override', as shown above, you won't catch that bug until
runtime.

With it, you'll catch it at compile time.
 
E

Eric Sosman

Is it really necessary to write @Override when you override or is this just "a good thing"?

Two benefits of @Override appear to me, one from its presence
and one from its absence:

- If you write @Override and then misspell the method name or
mess up the parameter list, Java will say "Hey, wait: There's
nothing in the superclass with this signature; what do you
think you're doing?" And then you'll say "Oops!" and fix
the problem, instead of wondering why your "overriding" method
doesn't seem to work.

- If you write a method and your IDE starts suggesting that you
ought to tag it with @Override, you'll be alerted that you've
overridden something you didn't intend to.[*]

Two benefits; that's all I see. Hence, like indentation and
Javadoc comments, not "really necessary" ...

[*] This actually happened to me earlier today. I was writing
a little Swing doodad to edit the "locations" of inventory items,
and I gave it a getLocation() method. NetBeans started clamoring
for @Override, and I realized that my doodad extended JPanel which
in turn extended JComponent, which already has a getLocation() ...
Time for "Facepalm!" and a quick name change.
 
L

Lew

Eric said:
bob said:
Is it really necessary to write @Override when you override or is this just "a good thing"?

Two benefits of @Override appear to me, one from its presence
and one from its absence:

- If you write @Override and then misspell the method name or
mess up the parameter list, Java will say "Hey, wait: There's
nothing in the superclass with this signature; what do you
think you're doing?" And then you'll say "Oops!" and fix
the problem, instead of wondering why your "overriding" method
doesn't seem to work.

- If you write a method and your IDE starts suggesting that you
ought to tag it with @Override, you'll be alerted that you've
overridden something you didn't intend to.[*]

Two benefits; that's all I see. Hence, like indentation and

And that wasn't enough?

Add the third benefit that I mentioned upthread. Aren't they enough now?

Is your disparaging tone rhetorical, or do you really find the
benefit of '@Override' to be that marginal?

Because it isn't.
Javadoc comments, not "really necessary" ...

Dental patient:
Is flossing my teeth really necessary? Which ones do
*really* need to floss?

Dentist:
Just the ones you want to keep!
[*] This actually happened to me earlier today. I was writing
a little Swing doodad to edit the "locations" of inventory items,
and I gave it a getLocation() method. NetBeans started clamoring
for @Override, and I realized that my doodad extended JPanel which
in turn extended JComponent, which already has a getLocation() ...
Time for "Facepalm!" and a quick name change.

That is an excellent anecdote to support the idea that the
'@Override' annotation is really necessary.

But only where you want to catch bugs at compile time before
they bite you in production.
 
G

Gene Wirchenko

Is it really necessary to write @Override when you override or is this just "a good thing"?

In my Visual FoxPro classes, I ended up annotating each method
with "base" or "overrides" to indicate whether the method was or was
not defined in a parent.

I have many classes that use parent class methods. I also have
to override these from time to time. The annotations help me keep it
all straight.

I tend to be very strict on using such aids. If you want to be
sloppy, you can do it, but do not think that you are doing yourself a
favour.

Sincerely,

Gene Wirchenko
 
D

Daniele Futtorovic

Eric said:
bob said:
Is it really necessary to write @Override when you override or is this just "a good thing"?

Two benefits of @Override appear to me, one from its presence
and one from its absence:

- If you write @Override and then misspell the method name or
mess up the parameter list, Java will say "Hey, wait: There's
nothing in the superclass with this signature; what do you
think you're doing?" And then you'll say "Oops!" and fix
the problem, instead of wondering why your "overriding" method
doesn't seem to work.

- If you write a method and your IDE starts suggesting that you
ought to tag it with @Override, you'll be alerted that you've
overridden something you didn't intend to.[*]

Two benefits; that's all I see. Hence, like indentation and

And that wasn't enough?

Add the third benefit that I mentioned upthread. Aren't they enough now?

Is your disparaging tone rhetorical, or do you really find the
benefit of '@Override' to be that marginal?

Because it isn't.
Javadoc comments, not "really necessary" ...

Dental patient:
Is flossing my teeth really necessary? Which ones do
*really* need to floss?

Dentist:
Just the ones you want to keep!
[*] This actually happened to me earlier today. I was writing
a little Swing doodad to edit the "locations" of inventory items,
and I gave it a getLocation() method. NetBeans started clamoring
for @Override, and I realized that my doodad extended JPanel which
in turn extended JComponent, which already has a getLocation() ...
Time for "Facepalm!" and a quick name change.

That is an excellent anecdote to support the idea that the
'@Override' annotation is really necessary.

But only where you want to catch bugs at compile time before
they bite you in production.

Uh... there was a (pretty long) time when people and programs *did*
manage to exist without that annotation, you know. No need to be overly
dramatic.
 
L

Lew

On 23/07/2012 22:59, Lew allegedly wrote:
&gt; Eric Sosman wrote:
&gt;&gt; bob smith wrote:
&gt;&gt;&gt; Is it really necessary to write @Override when you override or is this just &quot;a good thing&quot;?
&gt;&gt;
&gt;&gt; Two benefits of @Override appear to me, one from its presence
&gt;&gt; and one from its absence:
&gt;&gt;
&gt;&gt; - If you write @Override and then misspell the method name or
&gt;&gt; mess up the parameter list, Java will say &quot;Hey, wait: There's
&gt;&gt; nothing in the superclass with this signature; what do you
&gt;&gt; think you're doing?&quot; And then you'll say &quot;Oops!&quot; and fix
&gt;&gt; the problem, instead of wondering why your &quot;overriding&quot; method
&gt;&gt; doesn't seem to work.
&gt;&gt;
&gt;&gt; - If you write a method and your IDE starts suggesting that you
&gt;&gt; ought to tag it with @Override, you'll be alerted that you've
&gt;&gt; overridden something you didn't intend to.[*]
&gt;&gt;
&gt;&gt; Two benefits; that's all I see. Hence, like indentation and
&gt;
&gt; And that wasn't enough?
&gt;
&gt; Add the third benefit that I mentioned upthread. Aren't they enough now?
&gt;
&gt; Is your disparaging tone rhetorical, or do you really find the
&gt; benefit of '@Override' to be that marginal?
&gt;
&gt; Because it isn't.
&gt;
&gt;&gt; Javadoc comments, not &quot;really necessary&quot; ...
&gt;
&gt; Dental patient:
&gt; Is flossing my teeth really necessary? Which ones do
&gt; *really* need to floss?
&gt;
&gt; Dentist:
&gt; Just the ones you want to keep!
&gt;
&gt;&gt; [*] This actually happened to me earlier today. I was writing
&gt;&gt; a little Swing doodad to edit the &quot;locations&quot; of inventory items,
&gt;&gt; and I gave it a getLocation() method. NetBeans started clamoring
&gt;&gt; for @Override, and I realized that my doodad extended JPanel which
&gt;&gt; in turn extended JComponent, which already has a getLocation() ...
&gt;&gt; Time for &quot;Facepalm!&quot; and a quick name change.
&gt;
&gt; That is an excellent anecdote to support the idea that the
&gt; '@Override' annotation is really necessary.
&gt;
&gt; But only where you want to catch bugs at compile time before
&gt; they bite you in production.
&gt;

Uh... there was a (pretty long) time when people and programs *did*
manage to exist without that annotation, you know. No need to be overly
dramatic.

You sound like Grandpaw complaining that kids these days have it too easy.
"In my day, we had to check for ourselves whether the method overrode a
parent method!"

Your irrelevant observation does not give a reason to eschew '@Override'.

The fact is that Java *does* have it, and it *is* useful for the class of bugs
it helps prevent.

A point you ignore in your rush to fallacious argumentation.

That languages (including Java itself) didn't used to have
it is hardly an argument against it. In fact, that Java added it, given the
language's resistance to change, is strong evidence in favor of it.
So your evidence supports use of '@Override'. You drew exactly the
opposite of the correct conclusion from your data.
 
D

Daniele Futtorovic

You sound like Grandpaw complaining that kids these days have it too easy.
"In my day, we had to check for ourselves whether the method overrode a
parent method!"

Your irrelevant observation does not give a reason to eschew '@Override'.

The fact is that Java *does* have it, and it *is* useful for the class of bugs
it helps prevent.

A point you ignore in your rush to fallacious argumentation.

That languages (including Java itself) didn't used to have
it is hardly an argument against it. In fact, that Java added it, given the
language's resistance to change, is strong evidence in favor of it.
So your evidence supports use of '@Override'. You drew exactly the
opposite of the correct conclusion from your data.

And you sound like a drama queen. The fact that Java programs existed at
a point where @Override didn't exist proves that this annotation is not
strictly necessary. And the assiduous JLS reader that you are should
know that this hasn't changed.

Is that annotation a good thing? Yes. Should it be used? Absolutely.

As a matter of fact, its merits are such that with a minimum of
explanation, any sensible person would adopt it on their own. No need to
exaggerate or dramatize the issue. No need to try to ridicule me for
refusing your dramatization. Attempts like that to use coercion rather
than reason are counter-productive.
 
S

Silvio Bierman

Is it really necessary to write @Override when you override or is this just "a good thing"?

It is a lame patch for a language fault. Java SHOULD have required some
"override" keyword anytime a method that has a definition in a base
class is overridden in a derived class. Using an annotation is, as with
almost all uses of annotations, a poor attempt at making up for the lack
of a proper language feature.

Yes, it is better to use @Override than to not use it. However, the
compiler will only complain if you do use the annotation when you do not
actually override anything. If you simply leave it out there will be no
complaint.

Backward compatibility makes it impossible to enforce an override
keyword after the fact. Using an annotation as an afterthought is lame
but better than nothing.

Luckily, Scala has fixed this omission, amongst other things..
 
A

Arne Vajhøj

It is a lame patch for a language fault. Java SHOULD have required some
"override" keyword anytime a method that has a definition in a base
class is overridden in a derived class. Using an annotation is, as with
almost all uses of annotations, a poor attempt at making up for the lack
of a proper language feature.

Yes, it is better to use @Override than to not use it. However, the
compiler will only complain if you do use the annotation when you do not
actually override anything. If you simply leave it out there will be no
complaint.

Backward compatibility makes it impossible to enforce an override
keyword after the fact. Using an annotation as an afterthought is lame
but better than nothing.

True.

But we are still waiting for the language that gets everything right.

Arne
 
A

Arne Vajhøj

Well, it's "just a good thing," but it's *really* a good thing. If you
were programming professionally, you'd expect your boss (or coworkers,
say during a code review) to insist that you use @Override wherever
appropriate.

I think that it would slip through code reviews in many places.

I agree that it is a good thing.

Arne
 
L

Lew

On 23/07/2012 23:51, Lew allegedly wrote:
&gt; On Monday, July 23, 2012 2:40:21 PM UTC-7, Daniele Futtorovic wrote:
&gt;&gt; Uh... there was a (pretty long) time when people and programs *did*
&gt;&gt; manage to exist without that annotation, you know. No need to be overly
&gt;&gt; dramatic.
&gt;
&gt; You sound like Grandpaw complaining that kids these days have it too easy.
&gt; &quot;In my day, we had to check for ourselves whether the method overrode a
&gt; parent method!&quot;
&gt;
&gt; Your irrelevant observation does not give a reason to eschew '@Override'.
&gt;
&gt; The fact is that Java *does* have it, and it *is* useful for the class of bugs
&gt; it helps prevent.
&gt;
&gt; A point you ignore in your rush to fallacious argumentation.
&gt;
&gt; That languages (including Java itself) didn't used to have
&gt; it is hardly an argument against it. In fact, that Java added it, given the
&gt; language's resistance to change, is strong evidence in favor of it.
&gt; So your evidence supports use of '@Override'. You drew exactly the
&gt; opposite of the correct conclusion from your data.

And you sound like a drama queen. The fact that Java programs existed at

Ad hominem argument.
a point where @Override didn't exist proves that this annotation is not
strictly necessary. And the assiduous JLS reader that you are should
know that this hasn't changed.

I'm sorry, but where did I claim that the annotation is strictly necessary?

You're refuting a claim not made.

Straw-man argument.
Is that annotation a good thing? Yes. Should it be used? Absolutely.

So we agree.
As a matter of fact, its merits are such that with a minimum of
explanation, any sensible person would adopt it on their own. No need to
exaggerate or dramatize the issue. No need to try to ridicule me for
refusing your dramatization. Attempts like that to use coercion rather
than reason are counter-productive.

Like calling me names?

Physician, cure thyself.
 
A

Arne Vajhøj

Is it really necessary to write @Override when you override or is this
just "a good thing"?

Two benefits of @Override appear to me, one from its presence
and one from its absence:

- If you write @Override and then misspell the method name or
mess up the parameter list, Java will say "Hey, wait: There's
nothing in the superclass with this signature; what do you
think you're doing?" And then you'll say "Oops!" and fix
the problem, instead of wondering why your "overriding" method
doesn't seem to work.

- If you write a method and your IDE starts suggesting that you
ought to tag it with @Override, you'll be alerted that you've
overridden something you didn't intend to.[*]

Two benefits; that's all I see. Hence, like indentation and
Javadoc comments, not "really necessary" ...

I see the biggest benefits being the documentation.

It can be important to know that ones method may be called
by the super class.

And all arguments seems related to extends not implements, so
I m not convinced that extending it to interface methods was
wise.

Arne
 
G

Gene Wirchenko

[snip]
Backward compatibility makes it impossible to enforce an override
keyword after the fact. Using an annotation as an afterthought is lame
but better than nothing.

True.

But we are still waiting for the language that gets everything right.

And it is a very good thing that we are not holding our breaths
while doing so. Unless, of course, you REALLY like blue.

And assuming we ever agree on "right". If we do, there will be
one language only. Not likely. I prefer different languages for
different things, sometimes for opposite reasons.

Sincerely,

Gene Wirchenko
 
E

Eric Sosman

Is it really necessary to write @Override when you override or is this
just "a good thing"?

Two benefits of @Override appear to me, one from its presence
and one from its absence:

- If you write @Override and then misspell the method name or
mess up the parameter list, Java will say "Hey, wait: There's
nothing in the superclass with this signature; what do you
think you're doing?" And then you'll say "Oops!" and fix
the problem, instead of wondering why your "overriding" method
doesn't seem to work.

- If you write a method and your IDE starts suggesting that you
ought to tag it with @Override, you'll be alerted that you've
overridden something you didn't intend to.[*]

Two benefits; that's all I see. Hence, like indentation and
Javadoc comments, not "really necessary" ...

I see the biggest benefits being the documentation.

It can be important to know that ones method may be called
by the super class.

And all arguments seems related to extends not implements, so
I m not convinced that extending it to interface methods was
wise.

A separate @Implements annotation instead of @Override might
have been better for interfaces. But what should one do about
abstract methods in abstract superclasses? Are those @Override
or @Implements, or maybe @Concretizes? And why should the class
with the actual implementation care about the distinction? And
what about concrete methods *intended* to be overridden, as in
MouseAdapter? @ProFormaOverrides?

Looks like fodder for a "whichness of the why" debate.
 
A

Arne Vajhøj

On 7/23/2012 2:30 PM, bob smith wrote:
Is it really necessary to write @Override when you override or is this
just "a good thing"?

Two benefits of @Override appear to me, one from its presence
and one from its absence:

- If you write @Override and then misspell the method name or
mess up the parameter list, Java will say "Hey, wait: There's
nothing in the superclass with this signature; what do you
think you're doing?" And then you'll say "Oops!" and fix
the problem, instead of wondering why your "overriding" method
doesn't seem to work.

- If you write a method and your IDE starts suggesting that you
ought to tag it with @Override, you'll be alerted that you've
overridden something you didn't intend to.[*]

Two benefits; that's all I see. Hence, like indentation and
Javadoc comments, not "really necessary" ...

I see the biggest benefits being the documentation.

It can be important to know that ones method may be called
by the super class.

And all arguments seems related to extends not implements, so
I m not convinced that extending it to interface methods was
wise.

A separate @Implements annotation instead of @Override might
have been better for interfaces. But what should one do about
abstract methods in abstract superclasses? Are those @Override
or @Implements, or maybe @Concretizes? And why should the class
with the actual implementation care about the distinction? And
what about concrete methods *intended* to be overridden, as in
MouseAdapter? @ProFormaOverrides?

Looks like fodder for a "whichness of the why" debate.

I think abstract methods should be treated like other methods in
classes.

The abstract class could later introduce an implementation.

We know that the interface will never.

Arne
 
E

Eric Sosman

On 7/23/2012 4:35 PM, Eric Sosman wrote:
On 7/23/2012 2:30 PM, bob smith wrote:
Is it really necessary to write @Override when you override or is this
just "a good thing"?

Two benefits of @Override appear to me, one from its presence
and one from its absence:

- If you write @Override and then misspell the method name or
mess up the parameter list, Java will say "Hey, wait: There's
nothing in the superclass with this signature; what do you
think you're doing?" And then you'll say "Oops!" and fix
the problem, instead of wondering why your "overriding" method
doesn't seem to work.

- If you write a method and your IDE starts suggesting that you
ought to tag it with @Override, you'll be alerted that you've
overridden something you didn't intend to.[*]

Two benefits; that's all I see. Hence, like indentation and
Javadoc comments, not "really necessary" ...

I see the biggest benefits being the documentation.

It can be important to know that ones method may be called
by the super class.

And all arguments seems related to extends not implements, so
I m not convinced that extending it to interface methods was
wise.

A separate @Implements annotation instead of @Override might
have been better for interfaces. But what should one do about
abstract methods in abstract superclasses? Are those @Override
or @Implements, or maybe @Concretizes? And why should the class
with the actual implementation care about the distinction? And
what about concrete methods *intended* to be overridden, as in
MouseAdapter? @ProFormaOverrides?

Looks like fodder for a "whichness of the why" debate.

I think abstract methods should be treated like other methods in
classes.

The abstract class could later introduce an implementation.

We know that the interface will never.

Ah, but what about

abstract class Super implements ActionListener {
protected void helperMethod() { ... }
... // maybe an actionPerformed() here, maybe not
}

class NowWhat extends Super {
@WhatAnnotationGoesHere // ?
public void actionPerformed(ActionEvent evt) {
...
}
}

In the NowWhat class, does actionPerformed() "implement" the
method required by the ActionListener interface, or does it
"concretize" the abstract actionPerformed() method of the Super
class? Or does it "override" Super's concrete actionPerformed()
method (not shown)? What if Super explicitly declares an abstract
actionPerformed() method?

More to the point, is the distinction useful? No, let's
"concretize" that question: Can you suggest a scenario in which
it would be helpful to distinguish among different flavors of
overriding:

- Implement a method of an interface the class `implements'

- Implement a method of a superinterface of an interface
the class `implements'

- Implement a method of an interface an abstract superclass
`implements' but leaves abstract

- Implement a method explicitly declared as abstract by an
abstract superclass

- Replace a superclass' concrete implementation

At the risk of dating myself (again), where's the beef?
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,731
Messages
2,569,432
Members
44,832
Latest member
GlennSmall

Latest Threads

Top