Skip to main content

@Implement attribute

8 replies [Last post]
Joined: 2003-06-12

Similar to Override attribute, there should be @Implement attribute to flag if a method is implemented as interface contract.
It will help eliminate/refactor the unused code (code that is perhaps no longer needed) if a method from an interface is removed during the development.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joined: 2003-06-12

If you don't think @Override is useful, then perhaps you wont see the usefulness of @Implement as well. Two very good reasons for using this annotation.
1) If a method is marked @Implemented and before the Interface is shipped out, if there is a change in the interface definition, then it would require action for the implemented methods. Such as making them private, etc.
2)For marking interface implementation in an abstract class. Otherwise, there is no way to check such a thing to protect against typos etc. Consider that a developer assumed that she has provided the default implementation of an interface method in an abstract class and there is a typo. Now there is a big surprise waiting for you. Which can be enforced by compiler using @Implement.
Of course, you can write another tool for this. But there is always a right way. While using @Override, I was surprised that there is no such thing as @Implement or @Override didn't work with interface methods.

Message was edited by: chandra

Joined: 2004-11-25

You can use @Override annotation for interfaces. It works just as you want.

Joined: 2007-12-03

This is true for Java 6 and above only.
@Override does only work for classes in Java 5.

JFYI, Winne

Joined: 2009-09-18

The only benefit I see if adding the @Implemented annotation would be that if you removed a method from an interface and you had implementations of it, then you would get a compile time error to remind you to go and delete the implementations. To me this is just sloppy refactoring. You should delete all the implementations before you delete the method in the interface.

In the case of using a third party library it might be more useful. If the library owners delete the methods then you will know during compile time to go and delete the method implementations that are no longer needed and are only hanging around and cluttering your code. Yes a code analyzer would find these methods so you could use that if you like. That's no reason to not have another way to do it.

Annotations are meta-data for your code. I think jwenting should research all the possible uses of annotations before he says they are useless. When defining schema data for database tables most database frameworks (ie Hibernate) provide a way to use annotations to define the schema inside of the java class. Yes, this can be done in an xml file and I am sure there are other solutions, but the annotations solution is a good one.

I agree that if you go annotation crazy then you can start to clutter up your code, but the simple use of @Override or a new @Implemented can hardly be called messy and unreadable.

Joined: 2004-09-02

+1 over here ;)

The whole point of introducing Annotations is to provide a means to write down the thoughts and intentions of a programmer which are either unable or difficult to infer from a plain piece of code.

Joined: 2003-12-02

Like all annotations this shouldn't be needed.
If you remove a method from an interface a code coverage tool should be able to find unused implementations by itself, relying on some annotation is dangerous as it will lead to methods being removed that shouldn't be quite besides the point that annotations are evil in and off themselves as they're code that's there for no other purpose than to make the work of a tool easier at the cost of making the work of the programmer harder and heavier.

Joined: 2004-05-06

I don't think this annotation would be useless.

By using @Implement it is indicating the desire of the programmer by saying that this method implements an interface method.

A code coverage tool would indeed be able to find unused implementations, so long as all the code that implements that interface is loaded up. This is not possible with, for example, a project that relies on another project, possibly written by different companies. For example, if an open source library AlphaOrg decides to remove a method or two from one of their interfaces, they CAN analyze all their own code with the code coverage tool and avoid problems. But this does not help BetaCorp, a private company that has used AlphaOrg's library and wants to upgrade to the new version. If AlphaOrg has documented exactly what has changed, it's all well and good and BetaCorp can do a search for the methods in their code that were removed. But if not, then there is a problem. If @Implement was used by BetaCorp, then upon recompiling their code the compiler will warn them immediately exactly where these methods in their code lie.

Besides, if you really don't like annotations you don't have to use them. In JDK 1.5 you don't have to use @Override if you don't want to. The same would be true of @Implement.

Joined: 2003-12-02

With an external library your code would break if an interface in it changes.
I don't really see an external library defining one of your interfaces and something like this helping you any more than existing code analysers would.
Either they have your interface definition or their code won't even compile.

An application using that interface and class would have to have both and therefore there is again no problem.

A library writer shouldn't be responsible for outsiders using that library anyway, except insofar that the interface itself defines a contract which should not be broken, and removing a method from the interface breaks that contract already.