+1 Caleb On 08/28/2011 06:29 AM, Vincent Massol wrote:

Hi devs,

I've just realized that using @override is enough to generate a proper javadoc copied from the overriden method and that checkstyle doesn't complain either.

Basically instead of writing:

/** * {@inheritDoc} * * @see org.xwiki.logging.LoggerManager#popLogListener() */ @Override public EventListener popLogListener()

We can simply write:

@Override public EventListener popLogListener()

Advantages: 1) Less text to type and smaller class files 2) Less duplicated text

I thus propose to use this from now and to progressively remove unnecessary javadoc in our legacy code.

BTW this is also explained in the javadoc tool: See section "Automatic Reuse of Method Comments" in http://download.oracle.com/javase/1.3/docs/tooldocs/win32/javadoc.html

WDYT?

Here's my +1

Thanks -Vincent

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

On Aug 28, 2011, at 12:29 PM, Vincent Massol wrote:

Hi devs,

I've just realized that using @override is enough to generate a proper javadoc copied from the overriden method and that checkstyle doesn't complain either.

Basically instead of writing:

/** * {@inheritDoc} * * @see org.xwiki.logging.LoggerManager#popLogListener() */ @Override public EventListener popLogListener()

We can simply write:

@Override public EventListener popLogListener()

Advantages: 1) Less text to type and smaller class files 2) Less duplicated text

I thus propose to use this from now and to progressively remove unnecessary javadoc in our legacy code.

BTW this is also explained in the javadoc tool: See section "Automatic Reuse of Method Comments" in http://download.oracle.com/javase/1.3/docs/tooldocs/win32/javadoc.html

WDYT?

Here's my +1

ok in case you're wondering if using @override is valid when implementing an interface, here's a little detective work: 1) If you read Java 6 javadoc you'll find in http://download.oracle.com/javase/6/docs/api/java/lang/Override.html: "Indicates that a method declaration is intended to override a method declaration in a superclass. If a method is annotated with this annotation type but does not override a superclass method, compilers are required to generate an error message." So this seems to indicate it's not valid. However… 2) If your read http://blogs.oracle.com/ahe/entry/override_snafu you'll find that the javadoc for 1.6 isn't correct (read also http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5008260) and reading http://stackoverflow.com/questions/212614/should-a-method-that-implements-an... will show you that actually using @override is supported when implementing an interface in Java 6 but not in Java 5… ;) Some more reading about using @override: http://stackoverflow.com/questions/94361/when-do-you-use-javas-override-anno... Thanks -Vincent

+1 Thanks, Marius On Sun, Aug 28, 2011 at 1:29 PM, Vincent Massol <[email protected]> wrote:

Hi devs,

I've just realized that using @override is enough to generate a proper javadoc copied from the overriden method and that checkstyle doesn't complain either.

Basically instead of writing:

   /**     * {@inheritDoc}     *     * @see org.xwiki.logging.LoggerManager#popLogListener()     */    @Override    public EventListener popLogListener()

We can simply write:

   @Override    public EventListener popLogListener()

Advantages: 1) Less text to type and smaller class files 2) Less duplicated text

I thus propose to use this from now and to progressively remove unnecessary javadoc in our legacy code.

BTW this is also explained in the javadoc tool: See section "Automatic Reuse of Method Comments" in http://download.oracle.com/javase/1.3/docs/tooldocs/win32/javadoc.html

WDYT?

Here's my +1

Thanks -Vincent

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs