@override annotation not working correctly javac version _ 1.7.0_25

[Eric Sosman]

[...]
I see no error on the platform cited up-thread. You may have
adventitious classes in the classpath. Start with a clean build; failing
that, scrutinize your IDE's cache and your platform's java.ext.dirs.

"Adventitious classes" seems to me the most likely cause.
To expand and (I hope) explain:

Things like `int' and `throw' are built in to the Java
compiler, but names like `Runnable' and `MyClass' are not:
They are merely names, whose definitions need to be found
somewhere. When javac encounters `implements Runnable' it
doesn't somehow know you mean `implements java.lang.Runnable',
but must deduce your intent by searching for a suitable
definition of `Runnable'.

The problem (probably) is that javac when javac searches
for `Override', it finds some other `Override' before it finds
`java.lang.Override'. John B. Matthews already diagnosed one
of your other problems; in that one, you had an actual class
named `Override'. Well, if the file with that `Override' class
is in the same package as the file you're trying to compile,
javac will find that `Override' class -- and since the `Override'
class is not an `Annotation' (a special kind of `interface'),
it complains.

Try any of these:

1) Move all your other *.java files out of the current
directory and away to a desert island where javac won't find
them, then try compiling.

2) Rename your `Override' class to `Overturn' (you may
also need to rename the containing file), then try compiling.

3) Change `@Override' to `@java.lang.Override', then try
compiling.

4) Add `import java.lang.Override;' at the start of the
troublesome source, then try compiling.

If I'm right, any of these will fix your problem. In the
future, try to avoid reusing names already defined by Java's
class library -- especially those in the java and java.lang
packages, which are automatically visible to all compilations.
There are no reserved names (or almost no reserved names) in
Java, but you're just begging for trouble if you redefine them.

 

[Stanimir Stamenkov]

Fri, 6 Dec 2013 07:08:55 -0800 (PST), /Y HA/:

# javac CollectionTest.java
CollectionTest.java:14: error: incompatible types
@Override
^
required: Annotation
found: Override
CollectionTest.java:21: error: incompatible types
@Override
^
required: Annotation
found: Override
2 errors

# java -version
java version "1.7.0_45"
Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)

What about the javac version?

# javac -version

 

[Stefan Ram]

too error-prone. @Override gives
a compile-time error if the mothods actually doesn't override something.

»Implementing ones own annotation« could be read as to
include the creation of a custom annotation processor using
the Pluggable Annotation API (also supported by NetBeans).

Disclaimer: I don't know what can be checked with this API,
and how much effort it is to learn and use this API.

 

[Stefan Ram]

What about the javac version?

I'd also try »@java.lang.Override« instead of just »@Override«.
(I always write it this way.)

 

[Andreas Leitgeb]

Then I'm at a loss. File with strange characters? Unlikely,
if copy/paste from the web (which worked fine for me) still fails
for you. Corrupted Java installation? Again unlikely, since
you've re-installed.
Have you done something to anger the evil spirits? :-(
(In other words: I have no idea what's wrong. Sorry!)

one last straw: Y HA, maybe you have a file named Override.java in the
same folder as your test file?

 

[Y HA]

using @java.lang.Override seems to have worked...

why there was the need to specify java.lang.Override ?

 

[Andreas Leitgeb]

using @java.lang.Override seems to have worked...
why there was the need to specify java.lang.Override ?

because you didn't read the replies suggesting to remove or rename
the one "Override.java" that's likely in the same directory as your
test-programs...

 

[Eric Sosman]

using @java.lang.Override seems to have worked...

why there was the need to specify java.lang.Override ?

Because (as two or three people have explained) `Override' is
just a name, not something built in to the compiler like `throw'
or `float'. When your source contains `@Override', the compiler
realizes `Override' must be the name of something and sees that it
is an unqualified name: The package that defines the name has not
been specified. So the compiler searches in various places,
looking for a package that defines `Override'.

Usually, the compiler finds `Override' in the `java.lang'
package and concludes that the full name is `java.lang.Override'.
This particular definition of `Override' is of the right kind to
be used as an annotation, so all is well. But in your case there
was another `Override' definition, a class (probably in a file
named "Override.java") with `Override' as its name. The compiler
found this other `Override' first, and said "Aha! `Override' is
shorthand for `whatever.package.Override'." Unfortunately, your
`Override' was entirely the wrong sort of thing: A class, not a
sub-interface of `java.lang.annotation.Annotation'.

When you wrote `@java.lang.Override' in your source, the
compiler knew immediately what package contained the `Override'
definition that was needed. So the compiler didn't need to
search for anything, didn't find your non-Annotation `Override',
and went right ahead with the `java.lang.Override' version.

Names in Java are not globally unique; different packages
can define classes and interfaces and enums with the same name.
Java SE 7 includes two different things named `Parser', three
named `AttributeList', four named `Attribute', five named `Element',
and so it goes. How can all these colliding names coexist? They
are in different packages.

Usually, you import the package that defines the particular
kind of `FooBar' your source refers to (the compiler makes the
java and java.lang packages visible without the need to import).
Then you write `FooBar' in the source, and the compiler finds the
right definition among your imports. But occasionally you need
to deal with more than one kind of `FooBar' in the same source:
For example, you may use the `java.util.List' interface and the
`java.awt.List' class at the same time. When this happens, you
need to write out the full name; `List' by itself is ambiguous
when there's more than one kind of `List' in play. Similarly,
`Override' by itself is ambiguous when there's more than one.

 

[Stefan Ram]

because you didn't read the replies suggesting to remove or rename
the one "Override.java" that's likely in the same directory as your
test-programs...

A file »Override.java« is not necessary. Instead the
following Main.java will suffice:

class Override {} public class Main
{ public static void main( final java.lang.String[] args ){} }

, or any file named »Override.class«.

 

[Andreas Leitgeb]

because you didn't read the replies suggesting ...

After Stefan's correction:

because you didn't read the replies suggesting to remove or rename
the one "Override.java" and/or "Override.class" that's likely in the
same directory as your test-programs...

 

[Fredrik Jonson]

I'd even like @Override to allow a value indicating the class or
interface where the overridden method lives. For now, I'm (ab-)using
@see javadoc for this purpose, but that isn't part of the method's
signature and therefore doesn't show up as prominently in IDEs' code
completion suggestions etc.

I can see the point. I'd prefer a separate annotation for implemented
interface methods - say @Implement(Runnable.class) - but that'd mostly
be valuable if it also was a widely available standard annotation, like
@Override.

And yes, I like the @see approach, but indeed it isn't notable enough.
Not in a "if it compiles, ship it" situation anyway.

Having seen the discussion in this thread I think I'll be more lenient
towards @Override on interface methods, though I still think I prefer
the reduced clutter of leaving them out.

 

[Arne Vajhøj]

Sorry, I can't help with the problem, but the code made me curious.

Is it commont practice to use @Override when implementing interface
methods? Assuming that the method has not been implemented by a
superclass.

Obviously, the annotation is technically allowed, still it isn't really
possible to override an implementation that does not exist. And it
doesn't add type safety to the code, if your method signature doesn't
match the method signature of the interface, the implementing class
won't compile.

@Override was added in 1.5, but I believe that @Override was first
added in 1.6.

@Override in case of super class with non abstract method makes a
lot of sense as it turns some runtime bugs into compile time bugs.

@Override in case of super class with abstract method or
interface is a bit less obvious.

I don't use it myself.

But Eclipse generate them, so they are probably relative common.

Arne

 

[John B. Matthews]

@Override was added in 1.5, but I believe that @Override was first
added in 1.6.

@Override in case of super class with non abstract method makes a
lot of sense as it turns some runtime bugs into compile time bugs.

@Override in case of super class with abstract method or
interface is a bit less obvious.

I don't use it myself.

But Eclipse generate them, so they are probably relative common.

This matches my recollection. I've got some short examples from the
period that have the (permitted) superclass override annotation

static class MyLabel extends JLabel {

@Override
public Dimension getPreferredSize() {
...
}
}

and the (forbidden) interface implementation annotation in a comment.

public static void main(String[] argv) {
EventQueue.invokeLater(new Runnable() {

//@Override
public void run() {
...
}
});

More details on the 1.5/1.6 change are cited here:
<http://stackoverflow.com/q/2335655/230513>.