Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #26734 > unrolled thread

@override annotation not working correctly javac version _ 1.7.0_25

Back to article view | Back to comp.lang.java.programmer

Contents

  @override annotation not working correctly javac version _ 1.7.0_25 Y HA <yuriha@gmail.com> - 2013-12-05 14:42 -0800
    Re: @override annotation not working correctly javac version _ 1.7.0_25 Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-12-05 18:25 -0500
      Re: @override annotation not working correctly javac version _ 1.7.0_25 Y HA <yuriha@gmail.com> - 2013-12-05 16:13 -0800
        Re: @override annotation not working correctly javac version _ 1.7.0_25 Y HA <yuriha@gmail.com> - 2013-12-05 17:00 -0800
        Re: @override annotation not working correctly javac version _ 1.7.0_25 Y HA <yuriha@gmail.com> - 2013-12-05 17:03 -0800
          Re: @override annotation not working correctly javac version _ 1.7.0_25 Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-12-05 20:42 -0500
            Re: @override annotation not working correctly javac version _ 1.7.0_25 Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2013-12-07 19:15 +0000
    Re: @override annotation not working correctly javac version _ 1.7.0_25 "John B. Matthews" <nospam@nospam.invalid> - 2013-12-05 21:49 -0500
    Use of @Override when implementing interfaces (was: @override annotation not working...) Fredrik Jonson <fredrik@jonson.org> - 2013-12-06 07:01 +0000
      Re: Use of @Override when implementing interfaces Silvio <silvio@internet.com> - 2013-12-06 09:10 +0100
        Re: Use of @Override when implementing interfaces Y HA <yuriha@gmail.com> - 2013-12-06 07:08 -0800
          another error with @Override  with another code Y HA <yuriha@gmail.com> - 2013-12-06 07:25 -0800
            Re: another error with @Override  with another code "John B. Matthews" <nospam@nospam.invalid> - 2013-12-06 11:29 -0500
              Re: another error with @Override  with another code Y HA <yuriha@gmail.com> - 2013-12-06 09:21 -0800
                Re: another error with @Override  with another code "John B. Matthews" <nospam@nospam.invalid> - 2013-12-07 00:26 -0500
                  Re: another error with @Override  with another code Knute Johnson <september@knutejohnson.com> - 2013-12-06 21:57 -0800
                  Re: another error with @Override  with another code Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-12-07 08:44 -0500
                Re: another error with @Override  with another code "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2013-12-07 11:12 +0000
          Re: Use of @Override when implementing interfaces Stanimir Stamenkov <s7an10@netscape.net> - 2013-12-07 16:32 +0200
            Re: Use of @Override when implementing interfaces Y HA <yuriha@gmail.com> - 2013-12-08 12:02 -0800
              Re: Use of @Override when implementing interfaces Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2013-12-08 21:27 +0000
                Re: Use of @Override when implementing interfaces Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2013-12-08 23:43 +0000
              Re: Use of @Override when implementing interfaces Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-12-08 16:45 -0500
      Re: Use of @Override when implementing interfaces Jeff Higgins <jeff@invalid.invalid> - 2013-12-06 09:51 -0500
      Re: Use of @Override when implementing interfaces leif.roar@invalid.com (Leif Roar Moldskred) - 2013-12-06 09:36 -0600
        Re: Use of @Override when implementing interfaces Y HA <yuriha@gmail.com> - 2013-12-06 07:41 -0800
        Re: Use of @Override when implementing interfaces markspace <markspace@nospam.nospam> - 2013-12-06 08:18 -0800
      Re: Use of @Override when implementing interfaces v_borchert@despammed.com (Volker Borchert) - 2013-12-07 07:14 +0000
        Re: Use of @Override when implementing interfaces Wayne <nospam@all.invalid> - 2013-12-07 04:46 -0500
          Re: Use of @Override when implementing interfaces v_borchert@despammed.com (Volker Borchert) - 2013-12-07 10:54 +0000
        Re: Use of @Override when implementing interfaces Fredrik Jonson <fredrik@jonson.org> - 2013-12-09 12:59 +0000
      Re: Use of @Override when implementing interfaces Arne Vajhøj <arne@vajhoej.dk> - 2013-12-09 21:06 -0500
        Re: Use of @Override when implementing interfaces "John B. Matthews" <nospam@nospam.invalid> - 2013-12-11 00:55 -0500

Page 2 of 2 — ← Prev page 1 [2]

#26784 — Re: Use of @Override when implementing interfaces

Y HA <yuriha@gmail.com> wrote:
> 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...

[toc] | [prev] | [next] | [standalone]

#26787 — Re: Use of @Override when implementing interfaces

Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> wrote:
> Y HA <yuriha@gmail.com> wrote:
>> 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 ...

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

[toc] | [prev] | [next] | [standalone]

#26785 — Re: Use of @Override when implementing interfaces

On 12/8/2013 3:02 PM, Y HA wrote:
>
>
> 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.

-- 
Eric Sosman
esosman@comcast-dot-net.invalid

[toc] | [prev] | [next] | [standalone]

#26745 — Re: Use of @Override when implementing interfaces

On 12/06/2013 02:01 AM, Fredrik Jonson wrote:
> Y HA wrote:
>
>>   class Task implements Runnable {
>>       @Override
>>       public void run() {
>>           System.out.println("Run method overridden in Task class");
>>       }
>>   }
>
> 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.
>
Some interesting discussion around this Netbeans bug report.
<https://netbeans.org/bugzilla/show_bug.cgi?id=118928>

[toc] | [prev] | [next] | [standalone]

#26750 — Re: Use of @Override when implementing interfaces

Fredrik Jonson <fredrik@jonson.org> wrote:
> 
> 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.
> 

In my experience, it's not _uncommon_, but I wouldn't say it's common
either. 

It can be useful to have @Override in place on interface methods when 
you're refactoring or otherwise modifying the interface being 
implemented, in particular it helps to prevent dead code when you
delete methods from an interface.

-- 
Leif Roar

[toc] | [prev] | [next] | [standalone]

#26751 — Re: Use of @Override when implementing interfaces

well, I'm picking up Java again

I don't have experience coding in Java, and found this code that supposedly runs with 1.7  but the same error happens with other @Override sample code...

[toc] | [prev] | [next] | [standalone]

#26752 — Re: Use of @Override when implementing interfaces

On 12/6/2013 7:36 AM, Leif Roar Moldskred wrote:
>
> In my experience, it's not _uncommon_, but I wouldn't say it's common
> either.
>
> It can be useful to have @Override in place on interface methods when
> you're refactoring or otherwise modifying the interface being
> implemented, in particular it helps to prevent dead code when you
> delete methods from an interface.
>

Also, if the interface were less well known that Runnable, it would be 
helpful for a maintainer to see which methods were overridden.

public class Fubar implements ArgleBargle {

   public void doThing() {}

   @Override
   public void otherThing() {}

}

This makes one suspect that "doThing"is not part of the ArgleBargle 
interface, but something new added in Fubar.

[toc] | [prev] | [next] | [standalone]

#26758 — Re: Use of @Override when implementing interfaces

Fredrik Jonson wrote:

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

It helps reading the code of classes that have many methods, maybe
some of them with similar sounding names, but only fsw implementing
some not so well-known interface.

For that reason, 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'm a doctor, not a mechanic." Dr Leonard McCoy <mccoy@ncc1701.starfleet.fed>
"I'm a mechanic, not a doctor." Volker Borchert  <v_borchert@despammed.com>

[toc] | [prev] | [next] | [standalone]

#26759 — Re: Use of @Override when implementing interfaces

On 12/7/2013 2:14 AM, Volker Borchert wrote:
> Fredrik Jonson wrote:
> 
>> Is it commont practice to use @Override when implementing interface
>> methods? Assuming that the method has not been implemented by a
>> superclass.
> 
> It helps reading the code of classes that have many methods, maybe
> some of them with similar sounding names, but only fsw implementing
> some not so well-known interface.
> 
> For that reason, 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.
> 

Instead of that, why not create your own annotation, something like:

   @From("MyInterface")
   @Override
   public void someMethod () { ... }

-- 
Wayne

[toc] | [prev] | [next] | [standalone]

#26760 — Re: Use of @Override when implementing interfaces

Wayne wrote:
> On 12/7/2013 2:14 AM, Volker Borchert wrote:
> > 
> > For that reason, 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.
> > 
> 
> Instead of that, why not create your own annotation, something like:
> 
>    @From("MyInterface")
>    @Override
>    public void someMethod () { ... }

Too verbose, too non-standardized, and too error-prone. @Override gives
a compile-time error if the mothods actually doesn't override something.

-- 

"I'm a doctor, not a mechanic." Dr Leonard McCoy <mccoy@ncc1701.starfleet.fed>
"I'm a mechanic, not a doctor." Volker Borchert  <v_borchert@despammed.com>

[toc] | [prev] | [next] | [standalone]

#26799 — Re: Use of @Override when implementing interfaces

In <l7uhrq$7oj$1@Gaia.teknon.de> Volker Borchert wrote:

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

-- 
Fredrik Jonson

[toc] | [prev] | [next] | [standalone]

#26813 — Re: Use of @Override when implementing interfaces

On 12/6/2013 2:01 AM, Fredrik Jonson wrote:
> Y HA wrote:
>
>>   class Task implements Runnable {
>>       @Override
>>       public void run() {
>>           System.out.println("Run method overridden in Task class");
>>       }
>>   }
>
> 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

[toc] | [prev] | [next] | [standalone]

#26833 — Re: Use of @Override when implementing interfaces

On 12/9/13, 9:06 PM, Arne Vajhøj wrote:
> On 12/6/2013 2:01 AM, Fredrik Jonson wrote:
>> Y HA wrote:
>>
>>>   class Task implements Runnable {
>>>       @Override
>>>       public void run() {
>>>           System.out.println("Run method overridden in Task class");
>>>       }
>>>   }
>>
>> 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.

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

-- 
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.java.programmer

csiph-web