I've found the @Override annotation useful to detect when you didn't intend to override a method. For example, using Eclipse warnings, I found a finalize() method. This method was explicitly called from another class. I'm pretty sure the original author did not intend the garbage collector to call this finalize method.
I've also run across "boolean equals(T)" method implementations where I'm sure the authors intent was to override the "boolean equals(Object)" method. Chas On 3/8/12 10:39 AM, "sebb" <seb...@gmail.com> wrote: >On 8 March 2012 08:04, Emmanuel Bourg <ebo...@apache.org> wrote: >> Le 08/03/2012 02:21, Konstantin Kolinko a écrit : >> >> >>> Google shows ~1500 hits for "toStrng". >> >> >> More precisely 377 hits for "toStrng" + Java, versus 21,000,000 hits for >> toString, which is about 0.001%. >> >> So @Override is useless 99.999% of the time in this case. > >That's not a valid conclusion, because it does not take into account >whether @Override is present or not. >Besides, toString is extremely well known as a method name. > >== > >The point is, @Override is useful as documentation of the intention of >the coder. > >You may not find it useful for your own code - so don't use it in your >own code. > >However, ASF code is developed by many different people over a long >period of time, and having this annotation helps communicate the >intention of the coder to subsequent maintainers. > >--------------------------------------------------------------------- >To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
