Skip to main content

@Implements annotation

15 replies [Last post]
subanark
Offline
Joined: 2004-11-26
Points: 0

Random though of the day:

Since we have an @Override annotation, why not an @Implements annotation to indicate that a method helps implement an interface. This would be useful mainly for readability, and also catches any typoes when constructing abstract classes.

<br />
package java.lang;<br />
import java.lang.annotation.Target;<br />
import java.lang.annotation.Retention;<br />
import java.lang.annotation.RetentionPolicy;<br />
@Target(RetentionPolicy.METHOD)<br />
@Retention(RetentionPolicy.SOURCE)<br />
public @interface Implements<br />
{<br />
   /**<br />
   * The set of interface that the speficied method implements<br />
   */<br />
   Class[] value();<br />
}<br />

e.g.

<br />
import java.util.*;<br />
public class SequenceList extends AbstractList<br />
{<br />
   int start;<br />
   int size;<br />
   public SequenceList(int start,int end)<br />
   {<br />
      this.start = start;<br />
      this.end = start-end;<br />
   }<br />
   @Implements(List.class)<br />
   public Integer get(int index)<br />
   {<br />
      if(index < 0 || index >= size)<br />
         throw new IndexOutOfBoundsException();<br />
      return start+index;<br />
   }</p>
<p>   @Implements(Iterable.class,Collection.class)<br />
   public Iterator iterator()<br />
   {<br />
      return new Iterator()<br />
      {<br />
         int count = 0;<br />
         @Implements(Iterator.class)<br />
         public boolean hasNext()<br />
         {<br />
            return count < size;<br />
         }<br />
         public Integer next()<br />
         {<br />
            if(!hasNext())<br />
               throw new NoSuchElementException();<br />
            return start+count++;<br />
         }<br />
         public void remove()<br />
         {<br />
            throw new UnsupportedOperationException();<br />
         }<br />
      };<br />
   }</p>
<p>   @Implements(Collection.class)<br />
   public int size()<br />
   {<br />
      return size;<br />
   }<br />
}<br />

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
mord
Offline
Joined: 2010-10-05
Points: 0

The benefit would be to allow you to distinguish between overriden and implemented methods. The reason this distinction is useful is that in the case of an overriden method, you're quite often going to want to call the super implementation before adding your own code, something you do not do with a method you inherit from an interface.

For example:

public abstract class Foo
{
public void doFoo()
{
this.doReallyImportantInitialization();

}

}

public interface Bar()
{
public void doBar();

}

Today, a class extending Foo and implementing Bar would look like this:

public class MyClass extends Foo implements Bar
{

@Override
public void doFoo()
{
//your code
}

@Override
public void doBar()
{
//your code

}
}

With an @Implements annotation, it would like this:

public class MyClass extends Foo implements Bar
{

@Override
public void doFoo()
{
//your code
}

@Implements
public void doBar()
{
//your code
}

}

This extra distinction would help me catch the fact that I've ommitted to call super.doFoo() and as a result have not done the really important initialization that's handled in the super implementation.

jwenting
Offline
Joined: 2003-12-02
Points: 0

> Force? Just like @Override you are not forced to use
> it, its only a compiler error if you use it
> incorrectly. And in the case of @Implements, it would
> only be a compiler error if they method you denote as
> implementing an interface does not in fact implement
> that interface.
>
You are forced to use it because you're always going to have to use the code of others who use it.

> Annotations are for the most part just standardized
> comments that can optionality be compiled into the
> class file (like Depracated). They also help provide
> richer modifiers without adding another keyword to
> the language.
>
They are a keyword in themselves... Designed to turn documentation into code, something that should not be done.

> Besides its one less thing that a c# programmer
> cannot complain about java not having feature x.

Which should never be a reason to do anything. It should sooner be a reason to NOT do something.

subanark
Offline
Joined: 2004-11-26
Points: 0

Time to feed the Troll...

> You are forced to use it because you're always going to have to use the code of others who use it.

If someone else codes it you can safely ignore it, unless you do an incomplete refactoring and end up changing a method name of an interface that this class implements... and in that case its not to hard to correct, or you could just delete the annotation. The only real concern is weather an annotation actually does modify the behaviour of execution, which for the most part those that are currently implemented in the SDK do not.

>They are a keyword in themselves... Designed to turn documentation into code, something that should not be done.

When I talk about the adding a keyword I mean the problem of a language having too many keywords (or too many uses of those keywords), that requires users of the lanauge to activly know about (like c#). Annotations are kind of like keywords, except they are documented in the same way classes are, and must be imported or fully qualified to use. Image how much better java beans could be annotations were used instead of get___ or set___ method identifing names. Determining functionality at runtime by using patterns method names, class names, or package names, should be avoided!

> Which should never be a reason to do anything. It should sooner be a reason to NOT do something.

That was a joke.

kfgodel
Offline
Joined: 2005-12-22
Points: 0

Why is that you particularly don't like Annotations?
I know that using to much Annotations will make another language inside java. And we have to keep the coherence of one language with the force of many.
There are situations where Annotations can make things very easy, maybe we should use other form, more integrated with the rest of the language. What is your proposal for removing annotations?

kfgodel
Offline
Joined: 2005-12-22
Points: 0

Sorry, last post was directed to [i]jwenting[/i]

leouser
Offline
Joined: 2005-12-12
Points: 0

Im trying to understand the benefit of @Implements??

@Override is good, I use it and it has helped me out at times.

@Implements, where will it help me out?

The compiler already blows up if Im missing something and tells me: method so and so is not implemented. We also have
the implements keyword, which seems clear as well.

leouser

prunge
Offline
Joined: 2004-05-06
Points: 0

@Implements would pick up for example if I'm writing an abstract class that needs to still implement some methods of its interfaces.

It would also help if methods were removed from an interface, any class that implements the removed method would get picked up by the compiler.

leouser
Offline
Joined: 2005-12-12
Points: 0

hmm... interesting, someone should do a patch for this and submit it to the collab project. I wouldn't mind playing around with it to see how I like it. Mondo submitted a compiler patch, so someone could conceivably use that as a starting point for investigating implementation:
https://jdk-collaboration.dev.java.net/servlets/ProjectForumMessageView?...

leouser

chandra
Offline
Joined: 2003-06-12
Points: 0
alexlamsl
Offline
Joined: 2004-09-02
Points: 0

True - it will pair up with the usage of @Override quite well.

In fact, about standard Annotations - wouldn't @Deprecated be more useful if it has an optional String field which if specified contains the full qualified name to the alternative method?

subanark
Offline
Joined: 2004-11-26
Points: 0

I thought about this... and I did submit a proposial to one of the annotation JSRs about having other javadoc tags transform into annotations (e.g. Authors). It was ultimatly rejected though since it was thought that the javadocs style was a well accepted practice. @Depracated was added as an annotation only since it does make an actual change in the class file.

alexlamsl
Offline
Joined: 2004-09-02
Points: 0

oh I can understand your point; I propose this for usages beyond javadocs, though - e.g. friendlier compiler warnings, or even "automatic" legacy code transformation!

jwenting
Offline
Joined: 2003-12-02
Points: 0

Why the heck would we need annotations at all?
What's the added value, or is it (as it appears to me) change for the sake of change?

Annotations should never have made it into the language in the first place, let's not force them on people and make them even worse.

subanark
Offline
Joined: 2004-11-26
Points: 0

Force? Just like @Override you are not forced to use it, its only a compiler error if you use it incorrectly. And in the case of @Implements, it would only be a compiler error if they method you denote as implementing an interface does not in fact implement that interface.

Annotations are for the most part just standardized comments that can optionality be compiled into the class file (like Depracated). They also help provide richer modifiers without adding another keyword to the language.

Besides its one less thing that a c# programmer cannot complain about java not having feature x.

alexlamsl
Offline
Joined: 2004-09-02
Points: 0

Don't worry - there are always people who don't have enough resources to accomodate new ideas / innovations, and thus criticise them all and FORCE others from being able to utilise them.