@Override

R

Roedy Green

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

I asked for this in the days of Java 1.1. The syntax is a little
different that I had in mind, but it still has the same function. So
obviously I am keen on it.

I wanted it because sometimes I would override some method, but spell
it a little incorrectly or get the signature a little off. Then I
created an ambiguity sometimes calling the base method and sometimes
my new one. With @Override, if I don't get the match exact, I get an
error message.

I am big on ways for programs to cross check themselves for
consistency.
--
Roedy Green Canadian Mind Products
http://mindprod.com
The greatest shortcoming of the human race is our inability to understand the exponential function.
~ Dr. Albert A. Bartlett (born: 1923-03-21 age: 89)
 
R

Robert Klemme

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

Are variant of this is where the super class or interface is in a
library and a later version removed the method. You'll immediately
notice when replacing the lib with the newer version. This is a good
thing (being noticed - not removing something from a public API) and you
are immediately aware that your method won't be invoked the same way as
it used to be.

Granted this should be a rare situation but - for example - if the
library method had been deprecated and you somehow missed adjusting your
code to the imminent removal the compiler will force it on you once it
is gone.

Kind regards

robert
 
E

Eric Sosman

[...]
I will admit that the number of times it's helped me avoid a mistake are
far and few between. But it's happened, and it's certainly no large
inconvenience to have to include "override" (in fact, at least with the
Visual Studio IDE, it's a convenience, as VS will pop up a list of
overridable methods, and then auto-generate a skeleton method to fill in
for the override...maybe Eclipse, NetBeans, etc. would do the same?).

NetBeans will do two things about @Override (maybe more). It
will flag an overriding method that lacks an @Override annotation
and suggest that you add it (which you can do with a shortcut).
A feature I find even more convenient is that it notices when you
attempt to intantiate an abstract class, and suggests that you
provide overrides for the missing methods. Another shortcut, and
presto! it writes skeletons for the missing methods, with @Override
already in place. Saves the bother of hunting up the exact spelling
of a method name.

Illustration: If I type

button.addActionListener(new ActionListener(){});

.... NetBeans tells me I've failed to implement abstract methods.
After Alt-Enter and a confirming Enter, it rewrites my code as

button.addActionListener(new ActionListener() {
@Override
public void actionPerformed(ActionEvent e) {
throw new UnsupportedOperationException(
"Not supported yet.");
}
});

.... which I find very helpful, especially for interfaces that
have several abstract methods. (I've even been known to let
NetBeans expand MouseListener, then change it to MouseAdapter
and delete the auto-written methods I don't care about, just
to be sure I've got everything spelled properly.)
 
R

Robert Klemme

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.

That is nonsense. The mere fact that users can define their own
annotations along with handling these annotations demonstrates that
annotations solve problems which cannot be tackled by changing a
language's syntax. Annotations add *arbitrary* meta data to language
constructs; if all these would have to be handled by a language change
you would need a new Java for every custom library which requires
additional meta data.

Kind regards

robert
 
G

Gene Wirchenko

That is nonsense. The mere fact that users can define their own
annotations along with handling these annotations demonstrates that
annotations solve problems which cannot be tackled by changing a
language's syntax. Annotations add *arbitrary* meta data to language
constructs; if all these would have to be handled by a language change
you would need a new Java for every custom library which requires
additional meta data.

Let me add that useful annotations added by one user and group of
users might be useful only for them so changing the language would not
be a good fit.

Sincerely,

Gene Wirchenko
 
S

Silvio Bierman

On 7/23/2012 6:22 PM, Silvio Bierman wrote:

SNIP

True.

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

Arne

There is no such language and there never will be since it is and always
will be a moving target.

I am not saying that Scala is the perfect language for anyone, let alone
for everyone. But for me it is so extremely much closer to what I
need/want than Java that, since it is already available, it would be
stupid FOR ME not to use it. The fact that Scala happens to fix a lot of
Java design errors is a minor point, by the way.

For others it may be Groovy, Clojure or perhaps even Ruby if you are not
tied to the JVM. And for many staying with Java may be the most sensible
thing to do. But even then, it remains a fact of life that there will be
JVM languages that chose to fix Java omissions and mistakes.

For me one thing I like is that the Scala language developers are not
stuck on backward compatibility. They are not afraid to fix things, even
if that will break existing code. The language comes/exists in versions
and existing code may be tied to an older version. Does not have to be a
problem at all and the owner of the code can choose to update it if and
when he desires so.

If only they had done that with Java they could have fixed a lot of
annoying things. Now newer versions introduce new language features but
developers can not use them since their users do not want to upgrade to
the latest JVM. That is also a version problem, but then backwards.

Silvio
 
S

Silvio Bierman

That is nonsense. The mere fact that users can define their own
annotations along with handling these annotations demonstrates that
annotations solve problems which cannot be tackled by changing a
language's syntax. Annotations add *arbitrary* meta data to language
constructs; if all these would have to be handled by a language change
you would need a new Java for every custom library which requires
additional meta data.

Kind regards

robert

Well, I already really dislike annotations for their use in frameworks
like for example Hibernate or for all examples I have seen in "user code".
But to use it for plain language level constructs like @Override,
@NotNull etc. is plain ugly. Why have keywords like final, public, etc.
at all, then?

Someone really disliked the lack of an override keyword and since adding
that would break existing code they opted to introduce an annotation.
Perhaps we should introduce some to repair the design error that is the
combination of private, protected and public keywords with the ludicrous
default of package visibility when none of them is specified?

This way the language gets polluted using the generic annotation hammer.
Leave it be or actually fix it! I would applaud a bold language revision
that breaks backward compatibility for the benefit of fixing the
language. I could even imagine an annotation that could hint the
compiler at what language version a source is targeting.

Silvio
 
A

Arne Vajhøj

That is nonsense. The mere fact that users can define their own
annotations along with handling these annotations demonstrates that
annotations solve problems which cannot be tackled by changing a
language's syntax. Annotations add *arbitrary* meta data to language
constructs; if all these would have to be handled by a language change
you would need a new Java for every custom library which requires
additional meta data.

True.

There are two types of annotations:
* those acting as a supplement to the language
* those intended for runtime reflection

Arne
 
A

Arne Vajhøj

There is no such language and there never will be since it is and always
will be a moving target.

And both the problems to be solved and the people trying to solve them
are different.
I am not saying that Scala is the perfect language for anyone, let alone
for everyone. But for me it is so extremely much closer to what I
need/want than Java that, since it is already available, it would be
stupid FOR ME not to use it. The fact that Scala happens to fix a lot of
Java design errors is a minor point, by the way.

I also like Scala.

But I do not see it overtake the role of Java.

Two reasons:
- the language is not stable enough
- the language is too difficult
For others it may be Groovy, Clojure or perhaps even Ruby if you are not
tied to the JVM.

You can run Ruby in the JVM.
And for many staying with Java may be the most sensible
thing to do. But even then, it remains a fact of life that there will be
JVM languages that chose to fix Java omissions and mistakes.

For me one thing I like is that the Scala language developers are not
stuck on backward compatibility. They are not afraid to fix things, even
if that will break existing code. The language comes/exists in versions
and existing code may be tied to an older version. Does not have to be a
problem at all and the owner of the code can choose to update it if and
when he desires so.

If only they had done that with Java they could have fixed a lot of
annoying things. Now newer versions introduce new language features but
developers can not use them since their users do not want to upgrade to
the latest JVM. That is also a version problem, but then backwards.

A high level of backwards compatibility is a requirement in much
of the enterprise market.

Arne
 
A

Arne Vajhøj

NetBeans does that: Alt+Insert or right click and select "Insert
Code". I don't use Eclipse, so I can't comment on that IDE.

right click
refactor
override/implements methods
pick what one want

Arne
 
A

Arne Vajhøj

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?

I would tend to use the extend way here because Super
could implement the 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?

The beef is that it is not needed if it is known to be
an implements interface.

Arne
 
R

Robert Klemme

In all what you say below you do not address my argument. I take that
as agreement.
Well, I already really dislike annotations for their use in frameworks
like for example Hibernate or for all examples I have seen in "user code".

Do you have other arguments against annotations besides "dislike"?
(Btw., many people actually like JPA over previous versions of EJB
persistence just because lengthy XML files have been replaced by a few
annotations.) Do you at least concede that having the option to add
user defined type safe meta data to language constructs is a totally new
feature which allows to do things which cannot be done without?
But to use it for plain language level constructs like @Override,
@NotNull etc. is plain ugly. Why have keywords like final, public, etc.
at all, then?

It may be ugly - but it may actually be the best solution considering
all effects of language changes. I did not think through all the
effects of such a language change, did you?
This way the language gets polluted using the generic annotation hammer.
Leave it be or actually fix it! I would applaud a bold language revision
that breaks backward compatibility for the benefit of fixing the
language. I could even imagine an annotation that could hint the
compiler at what language version a source is targeting.

I am glad that it's not you who decides about the further evolution of
Java. These dramatic changes all too often look like a good idea
initially - and later turn out to be a nightmare when implemented
without thoughtfully considering all effects of that change.

The term "software" creates the illusion that code can be changed at
will. But in reality changing code (especially when it's part of a
public API) does have a cost - and it can be significant. I suspect
that this illusion is one of the reasons for so many project failures.

Cheers

robert
 
L

Lew

Arne said:
True.

There are two types of annotations:
* those acting as a supplement to the language
* those intended for runtime reflection

In many respects and for many purposes annotations obviate the need for
byte-weaving approachs like AspectJ's. Annotations arguably are the most
significant improvement to Java ever.

They make life ridiculously easy compared to not having them. For example,
JUnit4 tests are simpler than JUnit3 and safer because annotations replace
fragile and non-compiler-enforceable spelling conventions for method names.
JPA uses annotations to define object-to-RDBMS correlations. For Android
testing, annotations allow one to create multiple test suites off the same
code base with no recompilation. The topical '@Override' is a significant
assistance.

So many good things have come out of Java's adoption of annotations.

Silvio's opinion flies in the face of the evidence. It's an easy kind of thing
to say - wave your hands about "proper" language features without having to
say what the damage to the language might be or what such features might look
like or whether they're even feasible. It would be a much harder claim to make
if one were to enumerate all the "proper" language features that would be
needed to approximate the functionality of annotations. That exercise might
even force the retraction of the opinion, Gods forfend.
 
G

Gene Wirchenko

On Wed, 25 Jul 2012 07:57:00 +0200, Robert Klemme

[snip]
The term "software" creates the illusion that code can be changed at
will. But in reality changing code (especially when it's part of a
public API) does have a cost - and it can be significant. I suspect

I have read this idea before. I agree with it.
that this illusion is one of the reasons for so many project failures.

What's a little scope creep, eh? I suspect that people thinking
that since software can be changed, it must be easy to do so leads to
a lot of scope creep. That along with not designing in the first
place.

Sincerely,

Gene Wirchenko
 
A

Arne Vajhøj

Do you have other arguments against annotations besides "dislike"?
(Btw., many people actually like JPA over previous versions of EJB
persistence just because lengthy XML files have been replaced by a few
annotations.)

Many people prefer annotations over all those XML config files.

But I am also in disagreement about it.

A central XML config file is a cleaner solution than annotations
spread out in a large number of classes.

Replacing config XML is just one of many usages of annotations, so
it is not an argument against annotations.

Arne
 
A

Arne Vajhøj

In many respects and for many purposes annotations obviate the need for
byte-weaving approachs like AspectJ's.

????

I find it difficult to see non-intrusive build time behavior
modification being replaced not even partially by intrusive
runtime behavior modification.
Annotations arguably are the most
significant improvement to Java ever.

One could see at as that.
They make life ridiculously easy compared to not having them. For
example, JUnit4 tests are simpler than JUnit3 and safer because
annotations replace fragile and non-compiler-enforceable spelling
conventions for method names. JPA uses annotations to define
object-to-RDBMS correlations. For Android testing, annotations allow one
to create multiple test suites off the same code base with no
recompilation. The topical '@Override' is a significant assistance.

So many good things have come out of Java's adoption of annotations.

Silvio's opinion flies in the face of the evidence.

There has not been posted any evidence that for the first bullet
type of annotations that a language change would not have been a
better solution if one did not have to consider the backward
compatibility problem.

That leaves the "almost all" part. I am not even sure that evidence
against that has been presented. Plenty of examples of other usages
has made it look highly questionable though.

Arne
 
J

Jim Janney

Eric Sosman 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
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.

When you've overridden a class method in some third-party package and
then upgrade to a later version of that package, it sometimes turns out
that the method has been removed, or renamed, or given some additional
parameters. It's much nicer to get a compile-time error than to
eventually discover that your overriding method is no longer being
called. This has happened to me more than once with Hibernate.
 

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