|
Replies:
7
-
Last Post:
Aug 2, 2005 2:33 AM
by: jwenting
|
|
|
|
|
|
|
Proposal: Annotation @Optional
Posted:
Jun 22, 2005 11:29 PM
|
|
|
(I'm re-posting a proposal here that originally appeared in the "Generics" forum on java.sun.com. Leif Larsson pointed out that the Mustang forum might be the better place to discuss new Java features.)
I have a proposal for a new standard annotation with the following declaration:
@Retention(RetentionPolicy.CLASS)
@Target(ElementType.METHOD)
@interface Optional
{
}
This annotation would present a standard way of declaring interface methods as "optional".
@Optional would replace those tedious JavaDoc comments "this is an optional operation" just like @Deprecated will supersede the corresponding JavaDoc-tag.
This annotation shall be applied to method declarations of interfaces where it shall have the following effect:
Suppose the Annotation @Optional has been applied to a set of methods m(1)..m(n) of an interface I.
When the compiler compiles a non-abstract class C that implements I, it will check whether all methods declared within I are implemented in C. For all unimplemented methods that are contained in the set m(1)..m(n), the compiler will generate a method body that throws java.lang.UnsupportedOperationException
When compiling an abstract class, the annotation will be simply ignored.
Introducing this annotation will not raise any compatibility issues, since it will only have an effect on code that would otherwise not even compile!
Needless to say that I find this proposal totally cool, but what do you folks think?
|
|
|
|
|
|
|
Re: Proposal: Annotation @Optional
Posted:
Jun 23, 2005 3:53 AM
in response to: mcnepp
|
|
|
It does make things more precise compare to hand-coding UnsupportedOperationException.
|
|
|
|
|
|
|
|
|
Re: Proposal: Annotation @Optional
Posted:
Jun 23, 2005 4:02 AM
in response to: mcnepp
|
|
|
Good idea.
I suggest optional parameter to specify message of exception:
String message() default "";
|
|
|
|
|
|
|
|
|
Re: Proposal: Annotation @Optional
Posted:
Jun 23, 2005 10:41 AM
in response to: mcnepp
|
|
|
> This annotation would present a standard way of
> declaring interface methods as "optional".
I think this is a great idea. However from a design perspective, the general idea is that an implementation provides the detail for the contract specified in the interface. So if there is no need for that contract then it shouldn't be there. If there a need then couldn't we specify specialized contracts?
For example, EJB 3.0 is looking at these stubbed out interfaces that pollutes the code and redesigning the entire thing....
Of course, I am asking this not to contest the original idea but to consolidate my understanding....
|
|
|
|
|
|
|
|
|
Re: Proposal: Annotation @Optional
Posted:
Jun 23, 2005 1:46 PM
in response to: mcnepp
|
|
|
Interfaces shouldn't have "optional" methods.
That is an aberration. A horror.
Unfortunately we have to live with existing mistakes in the JDK.. but lets not make it easy to create more of these anti-pattern based solutions.
|
|
|
|
|
|
|
|
|
Re: Proposal: Annotation @Optional
Posted:
Aug 1, 2005 12:40 PM
in response to: dog
|
|
|
"...That is an aberration. A horror."
Wow, take ourselves pretty seriously, huh?
I actually agree, but I couldn't resist poking a little fun at the seriousness of your statement.
"Joe Shmoe wrote an optional method on an interface. This is a day that will live in infamy."
|
|
|
|
|
|
|
|
|
Re: Proposal: Annotation @Optional
Posted:
Aug 2, 2005 2:33 AM
in response to: rjlorimer
|
|
|
hmm, this would lead to some serious problems.
Annotations as a concept are abhorrent, so all annotations would have to be classed as "@optional @deprecated @dont-use @remove" including all those annotations themselves.
This leads to circular references...
|
|
|
|
|
|
|
|
|
Re: Proposal: Annotation @Optional
Posted:
Jun 23, 2005 5:01 PM
in response to: mcnepp
|
|
|
Rather than use an annotation, how about creating an abstract class that implements the interface and defines all optional methods as throwing an unsupported operation exception. Implementors can then extend the abstract class and override the methods they want to implement. An example of this is the AbstractList class in java.util.
While the annotation would allow interface writers would do slightly less coding, it's only a bit less and I don't think it warrants adding the @Optional annotation to Java.
|
|
|
|
|
java.net RSS
