Как правило, когда вы переопределяете метод, вы придерживаетесь контракта, определенного в базовом классе / интерфейсе, поэтому вы все равно не хотите изменять исходный javadoc. Поэтому использование тега @inheritDoc или @see, упомянутого в других ответах, не требуется и фактически служит только шумом в коде. Все разумные инструменты наследуют метод javadoc от суперкласса или интерфейса, как указано здесь :
Inherit from classes and interfaces - Inheriting of comments occurs in all
three possible cases of inheritance from classes and interfaces:
- When a method in a class overrides a method in a superclass
- When a method in an interface overrides a method in a superinterface
- When a method in a class implements a method in an interface
Тот факт, что некоторые инструменты (я смотрю на вас, Eclipse!) Генерирует их по умолчанию при переопределении метода, является лишь печальным положением вещей, но не оправдывает загромождение вашего кода бесполезным шумом.
Конечно, может быть и обратный случай, когда вы действительно хотите добавить комментарий к переопределяющему методу (обычно некоторые дополнительные детали реализации или сделать контракт немного более строгим). Но в этом случае вы почти никогда не захотите делать что-то вроде этого:
/**
* {@inheritDoc}
*
* This implementation is very, very slow when b equals 3.
*/
Почему? Потому что унаследованный комментарий может быть очень длинным. В таком случае, кто заметит дополнительное предложение в конце 3 длинных параграфов? Вместо этого просто запишите часть вашего собственного комментария и все. Все инструменты javadoc всегда показывают какую-то Указанную ссылку, по которой вы можете щелкнуть, чтобы прочитать комментарий базового класса. Нет смысла их смешивать.