I think I have shared my part in writing about the pro's and con's I
see for the @Mount annotation, and all I got in return was "I don't
like annotations".
Why does it have to be a HUGE improvement? Annotations *ARE* Java! Not
some foreign, alien construct: pure Java.
> than considering whether a plain Java alternative would be
> appropriate. We should not make the same mistake with annotations.
I don't buy the "annotations are replacements for XML configuration"
argument. Just because we do something inside class methods doesn't
mean it belongs there! We should not make the mistake to stay inside
the method. Annotations are a first class citizen in Java and should
be considered an equal alternative.
For instance the statelessness of a page. You specify that a page is
stateless. You now have to override a method to provide that logic,
but it is not logic... It is a configuration item that should be
orthogonal to the page. I find it much clearer to see this specified
in an annotation rather than some obscure overridden method 10 pages
down:
@Stateless
public class MyPage extends WebPage {
public MyPage() {
}
}
Don't get me wrong: I also don't want to spray arbitrary annotations
around. Having 10 annotations before a page would make that rather
illegible. However I am not going to ignore the usefulness of
annotations because of "I don't like them" arguments. They have good
uses, and I want to find those parts of our API that could better be
implemented using annotations than by subclassing and overriding.
Martijn
On Jan 11, 2008 9:11 PM, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
> On Jan 11, 2008 11:53 AM, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
> > I *still* haven't heard one single technical argument against using
> > annotations apart from Igor's concern that we would need to scan the
> > classpath.
>
> You could turn that around just the same. I haven't heard a good
> technical argument in favor of it.
>
> > Seriously all the "I don't like annotations" arguments are getting stale.
>
> The main concern vented in this thread by several people is that we
> should only introduce annotations if it leads to some big advantage. I
> don't see what is wrong with that attitude. In fact, I think it is
> very similar to our overall approach to API development.
>
> You could easily go ahead and implement a separate annotations library
> though. For those who would prefer that, it could be a nice extra. For
> the core project however, we should be conservative. I personally
> believe that one of the reasons why JEE ended up with a zillion of XML
> heavy projects was because many developers liked this new shiny tool
> that XML was a few years ago, and first thought of XML for solving
> their problems (even if that meant finding 'problems' first), rather
> than considering whether a plain Java alternative would be
> appropriate. We should not make the same mistake with annotations.
>
> My 2c,
>
> Eelco
>
--
Buy Wicket in Action: http://manning.com/dashorst
Apache Wicket 1.3.0 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0
